It has been common to make use of outliners in document preparation systems such as Lotus Manuscript.TM. and Microsoft Word.TM.. These systems are considered advanced word processing systems intended for the production of hardcopy documents. Outliners have also come into common use as so-called "thought processors" such as the Living Videotex program Thinktank.TM.. However these systems limit the user to outline editing only as opposed to using the outline for defining any database structure. While the Living Videotex follow up program More.TM. allows the user to perform simple time-management operations and organizational chart preparation in addition to simple outlining, none of the above outliners directly control a complex relational database or permit rearrangement thereof without complex database language reprogramming.
Note, with respect to word processors, these produce "linear" documents which have a clear beginning and end. All word processors provide simple word search and locate features but they perform these functions by locating the word searched in terms of its distance from the beginning of a document. This is a time-consuming scroll search function. Thus they lack advanced key word searching and word occurrence indices.
Also to full-text systems used in on-line and CD-ROM applications, they are constructed in a conventional word processing manner as linear documents having a clear beginning and clear end, with a table of contents. Although these systems use word occurrence indices for information retrieval, the index is invariant and prefabricated.
Thus, in all linear document systems, each selected word is located in the linear document solely from its distance from the beginning of the document. The context in which a particular word is used cannot be stated in a logical expression such as those used in database management systems, thereby making full-text or other linear document systems quite distinct from relational database management systems. Note a relational database is one in which there are one or more databases, each of which contain multiple fields having multiple records; and relations can be made between the fields of the databases. What this means is that in prior full-text or linear document databases, one cannot look for the occurrence of a word in a given field in a particular database, but rather the prior art linear document systems define the position of the word in the document by, for instance, stating how many characters to move from the beginning of the document.
Having discussed common linear document systems and their relative inflexibility as compared with relational database systems, common relational database capabilities nonetheless impose severe limitations. One of the most severe limits to relational database use is the requirement of a complex programming language to define and edit the structure of the database. This programming must be done by a skilled programmer, not the user of the system, which adds cost and complexity both when the database structure is to be changed. Also limits are imposed as to the number of fields per database, the number of records per database, and the number of databases in use during a query operation. Field lengths commonly must be preset to a specific length, typically not greater than 256 characters and must be "predeclared" as a specific type, such as numerical, alpha-numeric, date, or time. Record entry editing is limited to very simple single-line editing operations and commonly allow no carriage returns or text formatting of any kind. Alteration of the structure of such a relational database such as the insertion of a new field, renaming, deletion, or repositioning of an existing field is commonly an extremely cumbersome, if not impossible, operation once data records have been entered into a database. These limits make relational databases unsuitable for use in complex, text-oriented database management tasks.
It should be noted that no relational database management systems utilize an outliner-style text editor for the design of a set of databases and automatic generation of data entry forms. Data entry forms are expressed in a predetermined format and are that which, enable specifying the category definition and structure of the database for data entry. Also, no relational database management system uses an outliner as an interface for querying the database. Outlines reflecting the structure of interrelated databases are simply not utilized.
It should also be noted that so-called text databases commonly support the use of only one database at a time, thereby precluding any true relational operations between databases. Word occurrence indices are often utilized in text databases, but complex, multiple-criteria queries are either not supported or require the use of complex database programming language. Again, outlines are not used for the definition of the database or to perform data retrieval operations.
By way of example of the difficulties in the use of prior relational database systems, and considering the example of a medical student who wishes to construct a database about microbiology, using a common database program like Dbase.TM. II or III from Ashton Tate, the student must first define his database structures, one database at a time. As the database is defined he must declare the type of field, i.e., alpha-numeric, date, time, or formula, and the field length which is normally limited to a maximum of 256 characters. This field length remains fixed thereafter. As each database is defined, the user has nothing on screen that allows him to view the structure of other databases while he is designing a new one. Normally, users rely on printouts and other visual reminders. Once the structures are established for a set of databases, they cannot be conveniently changed. Thus the addition of new fields, changes of position, or changes of names is inconvenient at best. Databases like those in the Lotus products 1-2-3.TM. and Symphony.TM. only allow changes in the database to occur by having the user go through an arduous process of redefining numerous spread sheet ranges used in database operations and inserting or changing fields in all the ranges. The user interface provides no assistance in this process, so the user must remember that a change is only made when all the steps are gone through. The only assistance offered by the system is to deliver messages to the user that certain functions cannot be performed because the database is incorrectly defined; but no specific information about the nature of the error is given. Because of these restrictions on the structure and definition of the database, the student is severely hampered in the data entry phase, particularly in constructing a database for a complex subject such as microbiology where the student will come across facts for which no adequate database field exists and a change must be made. This frequently requires that the user start over which often results in lost data.
Database users, like the medical student, are most frequently non-programmers. Since common databases require the use of a database programming language to execute queries, non-programmers commonly employ database programmers or computer consultants to design and implement their database applications. Each time the user of a database application wants to ask a query that hasn't been asked before or wants to restructure the response, he must call upon the database programmer to write a query and revise the application. This requirement impacts negatively on user productivity and cost containment.